|
User-Managed Access （UMA）は、OAuthに基づくアクセス管理プロトコル標準である。 この標準のバージョン1.0は、2015年3月23日、Kantara Initiativeによって承認された。 UMAを開発したグループの憲章に記述されているように、プロトコル仕様の目的は「リソースオーナー（RO）が、オンラインサービス間で行われるデータ共有や他のリソースに対するアクセス認可を制御できるようにすること」にあり、これは、「POの代わりに、あるいは、ROによる認可 を伴って自律的なアクセス要求者（RqP）によって」行われる。 この目的には、標準化グループの参加者によって行われたケーススタディの収集によって探求されたように、WebアプリケーションとIoT（Internet of Things）についてのプライバシーと承諾が考慮されている 〔http://kantarainitiative.org/confluence/display/uma/Case+Studies〕。 == 経緯と背景 == Kantara InitiativeのUMA Work Group〔http://kantarainitiative.org/confluence/display/uma/Home UMA Work Group Wiki〕は、2009年8月6日にその最初の会合を開催した〔http://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes?src=contextnavchildmode UMA workgroup meeting minutes〕UMAの設計原則と技術的な設計は、2008年3月に始まったProtectServeと呼ばれたプロトコルについてのサン・マイクロシステムズ社の従業員による以前の作業によって知らされていた。 今度はProtectServeが、ベンダー関係管理（VRM）の動向と、「feeds-based VRM」と呼ばれる副次的活動の目標によって、影響を受けた。 ProtectServeとUMAの初期バージョンは、OAuth 1.0プロトコルを応用していた。 OAuthは、WRAP（Web Resource Authorization Protocol）仕様や、以降のOAuth 2.0のドラフトの発行を通じて大幅な変更を経たが、UMA仕様は追随し、現在、いくつかの主要プロトコルフローのためにOAuth 2.0系の仕様を使っている。 UMAは、OpenID 2.0をユーザ認証の手段として使ったり依存したりしない。 しかし、オプションとしてアクセス要求者（RqP）からアイデンティティクレーム（claim）を収集する手段として、認可を行うユーザのアクセスポリシーを満たすようにするために、OAuthに基づくOpenID Connect プロトコルを使う。 またUMA はXACML（eXtensible Access Control Markup Language）を、ユーザポリシーの符号化にも、アクセス認可のリクエストの手段としても、使ったり依存したりしない。 UMAは、ポリシーのフォーマットを指定しない。 UMAの観点からは、ポリシーに照らした判定は、ASにとって最初に行われるからである。 しかし、アクセス許可をリクエストするためのUMAプロトコルフローは、XACMLプロトコルといくつか共通の機能をもつ。 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「User-Managed Access」の詳細全文を読む スポンサード リンク
|